This package is a small add-on to ODF 1 to support the MacApp and PowerPlant view systems and their visual tools Ad Lib and Constructor.
With this add-on ODF can now understand the resource format of MacApp and PowerPlant views. An ODF part can load Views and PPob resources and convert them at runtime into ODF views. The part's UI can thus be built with Ad Lib and Constructor.
What are the benefits for developers?
• Choice of visual editors: you can now use Ad Lib or Constructor to build your part's UI (ODF also supports AppMaker, see the folder ":Tools & Goodies:AppMaker demo:"). Ad Lib is the standard visual editor for MacApp. Constructor is part of the Metrowerks CodeWarrior tools.
• Faster UI development with a "Reload Views" command: a developer can modify the Ad Lib or Constructor resource file while the ODF part is running and then reload it to update the part dynamically.
• Extensibility: custom views built in Ad Lib or Constructor can be supported by adding a minimal amount of code.
• Path for MacApp developers who want to port existing applications to ODF and get started quickly with the UI.
• Path for PowerPlant developers who want to support OpenDoc.
(Note: in the case of PowerPlant, developers will generally start with Metrowerks' PowerPart to add basic OpenDoc support to their existing PowerPlant application. When they are ready to move to ODF to get full OpenDoc support and cross-platform support, they will be able to re-use the same UI right away)
What is this release made of?
This release is an add-on to the existing ODF 1 kit, it doesn't modify ODF itself. It consists of the following files and folders to be installed over an existing ODF 1 release:
• A MacApp Views folder containing 2 source files for converting MacApp view resources.
• A PowerPlant PPob folder containing 2 source files for converting PowerPlant PPob resources (PPob is the resource type of PowerPlant views).
• A New ODF views folder containing 2 new useful view classes (Picture and Unknown).
• A modified ODF Form sample which demonstrates how to use this add-on in a part. Form can be built in 3 different ways by just changing a #define, using either ODF, MacApp or PowerPlant views.
• A new ODF ViewTester part which will load any MacApp or PowerPlant resource file and test the result of converted ODF views.
• A user guide (Read Me • User Guide) and two release notes covering technical details not included here: MacApp Views.doc, PowerPlant Views.doc (You can access the .doc files quickly within the projects ODFForm.π or ViewTester.π, they are listed with other source files)
How does it work? Was ODF modified?
The add-on works with the current ODF 1 release. No changes to the framework classes were necessary, all the code doing the loading and conversion of resources is isolated in a couple of files for MacApp and PowerPlant (*).
The main idea is to parse the resource stream the same way MacApp or Powerplant code does. For each view it builds an intermediate "factory" object containing the view's attributes, converts the attributes that ODF supports and creates the actual ODF object.
(*) There are a couple of patches required to make the "Reload Views" command to work. See the Installation procedures in MacApp Views.doc or PowerPlant Views.doc.
What are the main steps to use it with my part?
If you have an existing MacApp or PowerPlant application, run the ODF ViewTester to check the conversion of your views and windows.
To use it with your part you just need to add a couple of files to your ODF part's project (see ODF Form), add the resource file containing the views, and change your code to call the right CreateSubViewsFromXXXResource method to create your frame's views. If you use custom views you will need to add code to load them too.
See the file Read Me • Installation for the complete intallation notes.
What are the limitations?
The main limitation is that the ODF view system is not as complete as MacApp or PowerPlant, so certain view classes won't be converted. ODF 1 supports the standard controls, edit view, static text and list box classes. Any view that is not recognized during the conversion process is replaced by a special "unknown" view which displays a red rectangle in place of the view and shows its class id. This way it is very easy to find out what is not being converted. In many cases only a small amount of code is necessary to add support for unknown or custom views. In other cases there is no possible conversion (e.g. a grid view or multi-column table class that ODF doesn't have yet) and the developer needs to either change the UI or implement the same functionality in ODF.
Also, because of the fact that it has to deal with unknown objects, the code reading the MacApp or PowerPlant views cannot be 100% bullet-proof. However, when it fails, there is usually enough information to find out where the problem was and modify the original resource file.
Other limitations are:
• Menus built with Constructor are not supported.
• MacApp adorners and behaviors are ignored (except for the OK/Cancel buttons of a dialog window)
• An ODF frame can only have 1 scroller to display its content. MacApp or PowerPlant views containing more than 1 scroller will generate a warning and the scrollers will be ignored (however there are ways to handle additional scrollers, for instance for a text-edit view as demonstrated in Form.)
See the .doc release notes for more details on all these issues.
How does this help me convert my MacApp or PowerPlant code to ODF?
This add-on deals only with resources. The application code itself must be converted manually. However being able to re-use the same views helps make this process faster.
OK, ODF can now load MacApp or PowerPlant view resources, but can it save them back into its own resource format (ODFRC)?
Not in the first version. This feature will be added for the ODF 2 release.
It will be desirable to convert back to ODF resources for the final version of your part because this will save
about 40K of code necessary to load MacApp or PowerPlant views.
How do AppMaker, Ad Lib and Constructor compare as visual editors for ODF?
Ad Lib and Constructor are pretty close in functionality. Constructor is available to many developers because it is bundled with Metrowerks CodeWarrior. Both Ad Lib and Constructor generate only resource files, no source code, no header files containing view ids, etc. AppMaker's strength and flexibility comes from the fact that it is template-driven: it can be customized and it generates both ODF view resource definitions and source code (another advantage is that the generated ODF views can be compiled for other platforms). However AppMaker doesn't support custom classes.
What's Next?
The next version of this add-on will be rolled into the ODF 2 release at the end of this summer.
Try it and give us your feedback on the ODF-Interest list!
